8. WEB CONTENT MANAGEMENT
In SharePoint 2013, Microsoft paid
special attention to the Web Content Management (WCM) workload. With the
new search and managed meta-data improvements in the product,
SharePoint 2013 takes two different approaches toward publishing
content: structural and dynamic publishing models.
Now consider each model in more detail.
The Structural Publishing Model
This is how publishing sites work in
SharePoint 2010. Content authors create content pages individually and
make them available in publishing sites. For example, if you need to
create a detail page for a product called foo, you browse to the products site at http://www.tailspintoys.com/products
and you create a publishing page based on a predefined template (Page
Layout) to showcase foo as a product. After the page is checked in and
published, it serves as a detail page, and visitors can see that page by
typing the following URL in their browsers: http://www.tailspintoys.com/products/pages/foo.aspx.
This approach is useful for the content that needs
to live in SharePoint and is static in nature. After authoring content
pages, you need to somehow roll them up onto another page, often
referred to as the roll-up page. You can use a Content by Query Web Part
(CBQ) or other custom aggregation techniques to show your products in a
master/detail manner.
In a structural model, publishing content can be
moved and localized to variation sites using content deployment.
Alternatively, you can use content deployment to move the content across
your authoring and publishing farms and across the network boundary
between your intranet sites, extranet sites, and Internet sites.
The Dynamic Publishing Model
New in SharePoint 2013, roll-up and
detail pages can be automatically generated from the indexed content.
For example, your product catalogue, which in most organizations is kept
in non-SharePoint external systems, can be indexed by search and
automatically be included in SharePoint 2013 publishing sites.
Using the new managed meta-data feature, the
product pages can be accessed using much cleaner and more SEO-friendly
URLs such as http://www.tailspintoys.com/foo.aspx.
In dynamic publishing, content can then be made available to other sites using a new feature in SharePoint 2013 called cross-site publishing. Now look at how the dynamic publishing model works under the hood.
Taxonomy-Driven Navigation
Navigation infrastructure in SharePoint
2013 leverages taxonomy to generate SEO-friendly URLs and paths to
publishing pages. If you look at the navigation settings in a publishing
site, you should see that there are two ways you can design your site
navigation: structural and managed.
Structural navigation is what exists in SharePoint
2010. Managed navigation is new and is driven by site taxonomy. This is
an important concept because now you can abstract site navigation from
how your business operates without changing the underlying structure of
your sites. This also enables site owners to easily reorganize the
navigation by modifying the term sets.
Figure 18 shows the new managed navigation option in the Navigation Settings of a publishing site in SharePoint 2013.
It’s not just the navigation that can be based off
taxonomy. The next section discusses taxonomy-driven pages in
SharePoint 2013 WCM.
Term-Driven Publishing Pages
When a publishing page is created in
SharePoint 2013 using either structural or dynamic models, SharePoint
automatically adds a new term to the Site Navigation term set that
points to the new page. In addition, SharePoint automatically generates a
home page for that term just like social tag profiles.
The term’s home page is simply a Page Layout (.aspx)
that displays the content of the page. As always, developers and
designers have the opportunity to customize this template to meet
specific rendition requirements.
Through a new tab in the term store called Intended Use,
term sets can opt in to participate in taxonomy-driven navigation and
then further be customized. Selecting this option enables the Navigation
and Term-Driven Pages tabs, which enables you to customize features
such as friendly URLs, SEO options, target page settings, and many
others.
Cross-Site Publishing
If you have been programming for
SharePoint even for a short period of time, you probably know that
getting out of a site collection boundary and aggregating content across
multiple site collections is not an easy task. There are several
patterns and techniques to enable cross-site collection aggregation, but
they all require extra development effort and each one comes with its
own limitations.
SharePoint 2013 enables developers to make content
in lists and document libraries available for consumption on other site
collections. The idea is simple and involves a few high-level steps:
1. Create a list (or document library) with site columns and content types.
NOTE Only
site columns automatically have managed properties and appear in the
search index without any extra configuration efforts. If you use list
columns, you must create managed properties and map them to the crawled
properties of the list columns. Remember, cross-site publishing heavily
depends on indexed content.
2. Designate the list as a Catalog.
There is a new setting to do this in the list setting page. This makes
the content in the list available to other site collections through the
MMS applications. A catalog has a minimum of one Primary Key (a maximum of five) that uniquely identifies an item in the list. A catalog also has one column designated as Catalog Navigation.
Consuming site collections use this column to display it in their own
navigation hierarchy. The Catalog Navigation column is a Managed
Metadata field and is bound to a term set, referred to as a tagging term set.
3. Share the
catalog’s tagging term set with other consuming site collections using
the same technique discussed earlier in the “Enterprise Content
Management” section
4. Run a full
crawl, and ensure columns participating in the catalog (that is, Catalog
Navigation) are automatically queryable through managed properties on
the consuming site collections.
5. In the
consuming site collections, set the navigation to Managed Navigation.
See the “Taxonomy-Driven Navigation” section for more information.
6. Connect the consuming site collections, and connect to the catalog by browsing to Site Settings ⇒ Manage Catalog Connections.
Figure 19 shows an example of product catalog implementation in a consuming site collection.
When you click on an item on the roll-up page, the
page is created dynamically and directly from the search index. There
is no timer job involved in this process.
The notation of the catalog is so important in SharePoint 2013 that Microsoft decided to ship an out-of-the-box template called Product Catalog.
This template already has a designated list as a catalog named
Products. The idea is to give you a starting point to hit the ground
running toward building your own corporate product catalog system.
NOTE When
you combine new features introduced in ECM, WCM, and search together,
hopefully you can see a lot of potential to implement interesting
development scenarios such as cross-site collection navigation,
publishing, and deployment.
Before moving on to the next section, there are
two important things that need to be highlighted: First, the new
cross-site publishing feature in WCM is not meant to replace traditional
content deployment. There are still many scenarios where you should
prefer content deployment over cross-site publishing. For more
information, see the product documentation at http://msdn.microsoft.com/en-us/library/jj163225(v=office.15).aspx.
Second, structural and dynamic publishing and the
techniques used in each model are not mutually exclusive. They can
co-exist or be mixed together to enable complex publishing requirements.
For example, you can combine cross-site publishing with a variation to
enable authoring multilingual sites from a common authoring site
collection.
Hostname Site Collections
SharePoint 2007 supported extending a
web application to multiple zones and giving each zone a unique hostname
(host header). Because SharePoint has a limit in the number of web
applications hosted in a single farm, SharePoint 2010 introduced Host
Name Site Collections (HNSC) to address this scalability issue. The
problem was that HNSCs in SharePoint 2010 had to be in the Default zone
and couldn’t use alternative access mapping. In addition, there was only
one hostname per site collection.
SharePoint 2013 took HNSC to the next level by
supporting an unlimited number of hostnames per site collection and by
mapping each hostname to a zone at the web application level. You still
need to extend the web application, and there is a limit of five zones
per web application: Default, Intranet, Internet, Extranet, and Custom.
The difference, however, is how SharePoint 2013 enables hostnames to be
in different zones.
The following code snippet creates an HNSC with the URL http://www.bar.com in a web application with the URL http://foo. This web application has two zones: Default and Internet.
The code then adds additional URLs to the new HNSC; http://foo.bar.com to the Default zone and https://foo.bar.com to the Internet zone of the web application.
#Create a new HNSC
New-SPSite "http://www.bar.com" -HostHeaderWebApplication "http://foo" -Name "Bar
Portal" -Description "Bar Portal" -OwnerAlias "Tailspintoys\administrator"
-language 1033 -Template "STS#0"
# Get a reference to the new HNSC
$site = Get-SPSite 'http://www.bar.com'
# Add an alternative URL and map to Default zone
Set-SPSiteURL -Identity $site -Url http://foo.bar.com -Zone 0
# Add an alternative URL and map to Internet zone
Set-SPSiteURL -Identity $site -Url https://foo.bar.com -Zone 2
You can specify which zone to use (0 = Default zone and 2
= Internet zone) when creating the alternative names. If you list all
zones created for the new HSNC using the following code, you can see
what’s shown in Figure 20:
Get-SPSiteUrl -Identity http://www.bar.com
If the Internet zone of the web application supports anonymous access, so does the alternative URL used in HNSC.
Multilingual Features
If you live in a multilingual country
such as Canada, you probably know how important it is to enable users to
vary the presentation of their content in another language.
Variation has been always the primary feature in
SharePoint to satisfy multilingual requirements. Variation works based
on the following four principles to replicate content from a source to a
variation label (destination):
- URLs
- Language redirection
- Translation
- Content deployment
Variation is still constrained to one site
collection; however, it is a faster and much more reliable process in
SharePoint 2013. You get smaller export packages, and there is a
replication list that allows for easy start and stop of the replication
content. That means the content deployment is no longer a monstrous
all-or-nothing process; instead, you can select to replicate the entire
list or one or more variation labels at once.
Similar to terms in managed meta data, variations
in SharePoint 2013 support the ability to send site content to the
Machine Translation Service application. Alternatively, you can export
or import site content for translation by a third party in the industry
standard XLIFF format. When
exporting content you can include the entire variation label, one page,
or just a document. In case you need to develop your own custom
translation solutions, the Machine Translation Service object model is
similar to the Word Automation Services object model, and is available
in server-side as well as CSOM and REST.
NOTE When
the Machine Translation Service application receives a translation
request, it forwards the request to a Bing translation service in the
cloud. Communicate this with your clients up front.
By using Host-Named Site Collections (HNSC) and
friendly URLs in term-driven publishing pages, a multilingual resource
can be mapped to a URL that’s much easier to understand for search
engines and end users. For example, a publishing page called foo in a French site can be mapped to http://bar.fr/foo instead of http://www.bar.com/fr-fr/Pages/foo.aspx.
Another big change in Variation involves SEO
optimization. Page meta data emits the page locale for search engines.
In addition, SharePoint now uses HTTP 301 code instead of HTTP 302 for
homepage redirection, which is preferable for search engines.
The Content by Search Web Part
The Content by Query (CBQ) Web Part has
always been a powerful tool in publishing sites to fulfill content
aggregation and rollup requirements. Because publishing sites now
heavily rely on search to function, there is this new web part called
the Content by Search (CBS) Web Part.
Unlike CBQ, CBS is not constrained to one site
collection. It’s based on search, so it must to go beyond the site
collection boundary. For the same reason, the query results in CBS may
not be up to date. Aside from lag time, CBS renders only major versions
and cannot query content from site collections marked to be excluded
from the search. The simplest way to prove CBS queries are directly
served from the index is to reset the index and see how results are
instantaneously gone. You don’t want to prove this in production.
A query in CBS can be configured to aggregate
content based on values on the page or within the URL. Before the
results are rendered, you have the option to style them.
NOTE CBS
returns the results in raw XML format. Results can be styled using
snippets of HTML and JavaScript instead of XSLT. These snippets are
referred to as display templates in SharePoint 2013 and are stored in
the Master Page gallery.
Using display templates, it’s much easier to
customize CBS results than CBQ because you work with pure HTML and
JavaScript.
Design Manager
Microsoft recommends customers use SharePoint to
customize the product. To help do so, Microsoft has introduced another
tool called Design Manager, which helps customers customize SharePoint sites in a wizard-like approach.
Developers work with a designer or a design agency
to brand SharePoint. First, the developer receives the non-SharePoint
branding assets (HTML, CSS, images, and so on) from the design agency.
The design agency can create these files using any web design tool such
as Dreamweaver or Microsoft Expression. The developer uploads the
received files to SharePoint. Then, with a behind-the-scenes automatic
process, SharePoint-specific assets (*.master & *.aspx)
are generated. This process repeats until the branding task is
complete. Then the developer exports the branding assets and creates a
package (*.wsp) to deploy the custom brand to the production farm.
Figure 21 shows new Design Manager that replaces SharePoint Designer to customize SharePoint.
Design Manager provides a snippet gallery, so SharePoint controls can be quickly added to the design (refer to Figure 21).
The Ribbon on the top helps you find and add other SharePoint
components. When a new control is added, only HTML representation of the
control is generated, so the design agency can see how the control
looks in SharePoint, even if its toolsets don’t understand SharePoint.
When it sends the branding assets back, SharePoint ignores the HTML
representations and renders ASP.NET and SharePoint controls.
Design Manager is not perfect, but then again, this is the first iteration of the tool.
Mobile Support
SharePoint 2010 had support for mobile
devices, but it was rather limited and difficult to customize. New to
SharePoint 2013 are device channels. A device channel
can be targeted at specific mobile devices and associated with a master
page allowing for specific custom branding implementations for each
targeted device. In addition, site designers can decide which sections
of the Page Layouts should be included in a channel. This makes it easy
to manage the user experience on mobile devices.
You can configure device channels by browsing to
Site Settings ⇒ Look and Feel ⇒ Device Channels. This setting is only
available in publishing sites.
Image Rendition
SharePoint 2013 enables site owners to
optimize the user experience by creating different rendition formats for
media files used in their sites. This new feature is called image rendition but can be used for both images and videos.
When image rendition is properly configured,
SharePoint dynamically transforms an image to the settings specified in
its rendition and then it caches it on the web front end to serve future
requests. Because dynamic transformation to the appropriate rendition
setting is a costly operation, SharePoint 2013 relies on disk-based BLOB
caching to improve performance.
NOTE Image
rendition does not work until the disk-based Binary Large Object (BLOB)
cache is enabled for a web application. Disk-based BLOB caching is
disabled by default. For information about turning it on, see the
product documentation at http://msdn.microsoft.com/en-us/library/aa604896.aspx.
The process starts with site owners defining the
right renditions by browsing to Site Settings ⇒ Look and Feel ⇒ Image
Renditions on their sites. Simply, an image rendition has three
elements: name, height, and width.
After image renditions are defined, content
authors can upload an image, and then click the image hover panel to see
the different renditions in effect or click the Click to Change link to
further crop the image to ensure the important details in the image are
still focused after being resized by a specific rendition. At this
point, image rendition for the uploaded image is complete.
The next step would be for the content authors to pick the wanted image rendition when adding a media file to a page. Figure 22 demonstrates how a content owner is about to pick a rendition for the uploaded image optimized for viewing on Windows Phone 7.
Images with renditions can be referenced by any combination of rendition ID, width, or height. Here are two examples:
<img src="/sites/tp/PublishingImages/ppl.jpg?RenditionID=2"/>
<img src="/sites/tp/PublishingImages/ppl.jpg?Width=60"/>
When used with device channels, image renditions
can provide a great user experience on mobile devices. Image rendition
also helps reduce the bandwidth consumption on mobile devices for remote
users with bandwidth-constrained connections.
App-Driven Publishing Sites
The majority of public-facing websites
on the Internet are built using a SharePoint publishing template.There are many new capabilities and improvements
in WCM for building powerful public-facing websites. In addition to
those improvements, the new SharePoint apps can be leveraged within
public-facing sites to extend the user experience. For example, a
provider-hosted app can be used to inject a shopping card application to
the site, or a SharePoint-hosted app can be used to render a stock
ticker on the homepage of the site.
In summary, apps can be used to take some of the
functionality commonly developed for public-facing sites away from the
site and put it in the context of some companion apps that ship on the
side or in future iterations of the site.
